The present invention relates to Internet security mechanisms. More particularly, and not by way of limitation, the present invention is directed to a system and method for securing Internet communications using a resilient IP security/Internet key exchange security gateway.
Abbreviations used herein shall have the following meanings:
B-SEG—Backup SEG
IKE—Internet Key Exchange
IP—Internet Protocol
IPsec—IP Security
M-SEG—Master SEG
PAD—Peer Authentication Database
SA—Security Association
SAD—Security Association Database
SADRRQ—SAD Recovery Request
SADRRP—SAD Recovery Reply
SADBRQ—SAD Build Request
SADBRS—SAD Build Response
SADBAck—SAD Build Acknowledgement
SATP—SA Transfer Protocol
SAURP—SA Update Reply
SAURQ—SA Update Request
SEG—Security Gateway
SPD—Security Policy Database
VID—Virtual SEG ID
VIP—Virtual IP
VMAC—Virtual MAC
VRRP—Virtual Router Redundancy Protocol
V-SEG—Virtual Security Gateway
State-of-the-art IPsec protocols add origination-authentication and content-confidentiality of the IP packets to existing IP version 4 and IP version 6 standards using standardized data authentication and encryption algorithms. IPsec protection can be established between two end hosts to secure their communication channel and also between two SEG nodes to secure inter-network traffic traversing over an inherently insecure network. In both cases, end-to-end IPsec protection depends on establishment of unidirectional security associations (SA) at each peer node. At minimum, these SAs can be pre-configured manually, which does not scale well. To ease configuration issues and to protect the encryption keys in a scalable deployment, an IKE implementation is normally deployed together with an IPsec function. IKE allows for SAs between each peer node to be described beforehand, allowing the actual establishment of the IPsec SA to be deferred until traffic is exchanged. Time and byte limits can be imposed on the IPsec SA, limiting the amount of traffic for which single keys are used. Once these limits expire, IKE renegotiates the IPsec SA with its peer, and generates brand new keys for IPsec encryption and authentication.
When an IPsec/IKE enabled SEG crashes, all IPsec SAs, created dynamically via IKE, become unusable. Disadvantageously, there exists no mechanism to maintain existing IKE and IPsec SAs when one of the devices that negotiated them fails. There exists no resiliency mechanism for IKE. As a result all such SAs are deleted and renegotiated (if possible).
FIG. 1 illustrates IPsec/IKE 100 between 2 SEGs 101, 102. Assume two IPsec/IKE peers, SEG Node A (SEG-A) 101 and SEG Node B (SEG-B) 102, have negotiated an IKE SA and at least one child IPsec SA between them. If SEG-B 102 fails, SEG-A 101 does not immediately detect the failure, and as such, SEG-A 101 will continue to send data to SEG-B 102. Because SEG-B 102 has failed, it does not receive that data, thus all packets sent on the IPsec SA by the SEG-A 101 are black-holed. When this situation occurs, there are currently several possible subsequent events:
(1) SEG-B 102 does not restart;
(2) SEG-B 102 restarts and SEG-A 101 does not have a dead peer detection scheme; or
(3) SEG-B 102 restarts and SEG-A 101 has a dead peer detection scheme.
If SEG-B 102 does not restart, SEG-A 101 cannot communicate with SEG-B 102 and encrypted communication will stop. Upon IPsec SA expiration, SEG-A 101 is unable to negotiate a replacement IPsec SA. In this case, encrypted traffic between SEG-A 101 and SEG-B 102 completely stops.
If SEG-B 102 restarts, but SEG-A 101 does not have a dead peer detection scheme, SEG-A 101 will have to wait until the IKE SA on SEG-A 101 to SEG-B 102 times out, which could be hours or even days. Upon the expiration of the IKE SA on SEG-A 101, SEG-A 101 will delete all child IPsec SA(s) and the IKE SA. Then, SEG-A 101 can renegotiate an IKE SA and child IPsec SA and encrypted traffic can resume. In this case, encrypted traffic could be interrupted for hours or days.
If SEG-B 102 restarts and SEG-A 101 has a dead peer detection scheme, SEG-A 101 will learn about the failure of SEG-B 102 within a shorter period of time (seconds to minutes). Once SEG-A 101 has determined that SEG-B 102 has failed, SEG-A can delete its child IPsec SAs and parent IKE SA towards SEG-B 102. Then, SEG-A 101 can renegotiate an IKE SA and associated child IPsec SAs. As a result, encrypted traffic can resume. In this case, encrypted traffic could be interrupted for almost a minute or minutes.
It would be advantageous, in a high-availability deployment scenario, to have a network based resilient IPsec/IKE method and apparatus in which an IPsec/IKE peer may stop functioning but encrypted traffic is impacted minimally if at all. The present invention provides such a system and method.